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AUTOMATIC DISTRIBUTION OF CAPABILITY AND CONFIGURATION INFORMATION BETWEEN 
MOBILE SWITCHING CENTERS IN A MOBILE COMMUNICATIONS NETWORK 

Field of the Invention 

5 The present invention relates to mobile communication networl<s. In 

particular, and not by way of limitation, \he present invention is directed to a 
system and method for achieving interoperability between telecommunication 
servers in a mobile communication networl< by automatically distributing 
capability and configuration information between the servers. 

10 

Background Art 

In existing mobile communication networks, interoperability between 
telecommunication servers such as Mobile Switching Centers (MSCs) is 
achieved through several procedures. First, each MSG stores/administers the 

15 capabilities of neighboring/reachable MSCs in the network. Second, each MSG 
transmits to receiving MSCs, all of the information needed for the features 
supported by the transmitting MSC. This includes information for features that 
are not supported by the receiving MSC. Third, newly introduced features are 
designed in such a way that backwards compatibility is not hampered. 

20 There are several disadvantages of the existing procedures. Regarding 

network administration, the existing procedure of administering the capabilities of 
neighboring/reachable MSCs within each MSC utilizes a large amount of system 
resources. This is undesirable to network operators who must provide these 
resources even though the resources are not producing revenue. In addition, 

25 the procedufB has a good chance of causing system failures due to human 
errors such as typing mistakes. For example, if an operator owns 50 MSCs In 
his network, and every MSC must contain capabilities information for all the 
other MSCs," then changing the configuration of a single MSC requires updating 
the 49 other MSCs with this new information. 

30 The existing procedures also cause problems relating to bandwidth and 

processing capacity. Transmitting nodes currently transmit all of the information 
needed for the features supported by the transmitting MSC, even for features 
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that are not supported by the receiving MSG. This is a waste of networl< 
bandwidth and processing capacity at both the transmitting and the receiving 
MSCs. For example, at inter-MSC handover, the anchor MSG sends 
BSSMAP/Radio Access Network Application Part (RANAP) Service Handover 

5 information to the target (i.e., non-anchor) MSG even though the non-anchor 
MSG may not support this feature. By way of further example, the anchor MSG 
always includes Shared Network Information (SNA), if available. In cases where 
the SNA is too large to fit in the BSSMAP Handover Request message, the SNA 
is sent in an extra BSSMAP Gommon ID message. These messages are sent 

10 even if the non-anchor MSG does not support this feature, or where there is no 
need for the information (e.g., the non-anchor MSG is not serving a shared 
area). 

The design of newly introduced features in such a way that backwards 
compatibility is not hampered causes the introduction of inefficient functionality in 
15 the network. The Mobile Application Part (MAP) protocol ensures backward 
compatibility by initiating the MAP dialog between MSGs with the highest version 
supported by the initiating MSG. If the other MSG does not support this version, 
a fallback mechanism is utilized to downgrade to an older version of the protocol. 
In some cases, however, particularly in third generation systems, the proposed 
20 solutions for backward compatibility are overly complicated. In the 3rd 
Generation Partnership Project (3GPP), for example, for the introduction of 
codec negotiation over the E-interface, a complex solution has been proposed 
with the introduction of a new information element in order to ensure backward 
compatibility. The proposed solution also requires changing one of the major 
25 design principles in handover. 

Another example of inefficient functionality for the sake of backward 
compatibility, is found in the optional function of Inter-MSG SRNS Relocation for 
multiple bearers. The anchor MSG first tries the function with all bearers 
available. If the non-anchor MSG does not support multiple bearers, the non- 
30 anchor MSG rejects the first attempt. The anchor MSG then tries again, but with 
only one bearer selected. 
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Thus, there is much inefficiency in the existing procedures for achieving 
interoperability between MSCs in a mobile communication network. It would be 
advantageous to have a system and method for achieving interoperability by 
automatically distributing capability and configuration information between 
5 MSCs. 

Summary of the Invention 

The present invention enables interoperability between MSCs by causing 
each MSC to send operational information such as capability and configuration 

10 information to neighboring MSCs following a reconfiguration, reset, or any other 
procedure that may have changed the capabilities or configuration of the 
affected MSC. Each neighboring MSC that supports the invention responds by 
sending Its own capability and configuration information to the affected MSC. 
Thereafter, each MSC uses its knowledge of the capabilities and configuration of 

15 neighboring MSCs to send only the information that is needed to implement 
requested services or features. 

Thus, in one aspect, the present invention is directed to a method of 
automatically distributing operational information between MSCs in a mobile 
communication network. The method includes the steps of defining for each 

20 MSC in the network, at least one neighboring MSC; performing a procedure that 
changes the first MSCs operational information; and upon completion of the 
procedure, automatically sending the first MSCs operational information from 
the first MSC to the first MSCs neighboring MSCs. This Is followed by receiving 
and storing the first MSCs operational information in each of the first MSCs 

25 neighboring MSCs; and upon receiving the first MSCs operational information, 
sending operational information for each of the first MSCs neighboring MSCs 
from the neighboring MSCs to the first MSC. The operational information may 
include capability and configuration information. 

In another aspect, the present invention is directed to a method of 

30 reducing signaling and processing requirements in a mobile communication 
network having a plurality of neighboring MSCs. The method includes the steps 
of automatically distributing operational information between the MSCs 
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Whenever an operational capability of one of tlie MSCs is changed; initiating a 
service in a first MSG; and upon initiating the service in the first MSG, sending to 
MSGS neighboring the first MSG, only information that the operational 
information stored in the first MSG indicates is supported by the neighboring 
S MSGS. 

in yet another aspect, the present invention is directed to an MSG that 
automatically distributes operational information for the MSG to neighboring 
MSGs in a mobile communication network. The MSG includes a communication 
signaling mechanism that automatically sends the MSG'S operational information 

10 to at least one neighboring MSG upon start-up of the MSG, and receives in 
return, operational information for the at least one neighboring MSG. The MSG 
also Includes means for storing the operational information for the at least one 
neighboring MSG. The operational information may include capability and 
configuration information. The MSG may also include means for initiating a 

15 service; means for determining from the stored capability and configuration 
information for the at least one neighboring MSG, which information related to 
the initiated service is supported by the at least one neighboring MSG; and 
means for sending to the at least one neighboring MSG, only the service-related 
information that is supported by the at least one neighboring MSG. 

20 

Brief Description of the Drawings 

FIG. 1 is a simplified block diagram illustrafing a plurality of MSCs in a 
mobile communication network in which the present invention has been 
implemented; 

25 FIG. 2 is a signaling diagram illustrating the automatic exchange of 

capability and configuration information between MSGs in one embodiment of 

the present invention; and 

FIG. 3 Is a flow chart illustrating the steps of one embodiment of the 

method of the present invention. 
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Detailed Description of Embodiments 

FIG. 1 is a simplified block diagram illustrating a plurality of MSCs 11-16 
In a mobile communication network in which the present Invention has been 
implemented. In the exemplary configuration illustrated, the network operator 

5 has defined for MSC-1 that MSC-2, MSC-3, MSC-4, and MSC-5 are neighboring 
MSCs. MSC-6 is not a neighboring MSG. In addition, MSC-1 , MSC-2, and 
MSC-4 support the present invention. It is not relevant to the present invention 
whether or not MSC-6 supports the invention because MSC-6 is not a 
neighboring MSC. It should also be recognized that although the exemplary 

10 embodiment described herein utilizes the term "MSC", the invention is applicable 
to any telecommunication server. 

In an exemplary scenario, MSC-1 is reconfigured and/or reset. Just 
before MSC-1 starts operation, MSC-1 sends its capability and configuration 
information to all of its defined neighboring MSCs. This Is illustrated by the 

15 outgoing arrows from MSC-1 to MSC-2, MSC-3, MSC-4, and MSC-5. Since 
MSC-3 and MSC-5 do not support the present invention, they discard the 
information and continue to operate as before. Since MSC-2 and MSC-4 
support the present invention, they store the received information and consider 
the information during operation. In addition, as shown by the incoming arrows 

20 to MSC-1 , they send their own capability and configuration information to MSC- 
1. 

FIG. 2 is a signaling diagram illustrating the automatic exchange of 
capability and configuration information between MSCs in an exemplary 
embodiment of the present invention. It should be understood that the illustrated 

25 signaling messages and message contents are illustrative only, and that other 
messages, message formats, and message contents could also be utilized with 
the present invention. For simplicity, the interaction between only two MSCs is 
shown, but in reality the information is exchanged between the reset MSC and 
all of its defined neighbors that support the present invention. 

30 Once MSC-1 is reconfigured or switched on at step 21, MSC-1 sends a 

message such as a Configuration Capabilities Data Request message 22 to 
neighboring MSC-2. In the exemplary message shown, MSC-1 indicates that it 
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is compliant with tlie Third Generation Partnership Project (3GPP) release 
version 5 specification, it supports Shared Network Information (SNA), and it 
includes codec negotiation functionality. In addition, the message contains an 
indication of the SNA-information mapping utilized by MSC-1. This mapping 
5 enables MSC-1 to use a single value in communication with MSC-2 instead of a 
large amount of data (for example, the value 1 instead of r1 , r2, b2, and b3; or 
the value 2 instead of r2, r3, b1 , and b2). 

Once MSC-2 receives the Configuration Capabilities Data Request 
message 22, MSC-2 stores the included information, and uses the information to 

10 make future operations more efficient. For example, MSC-2 will never send 
Service Handover information to MSC-1 because MSC-2 knows that MSC-1 
does not support this information. In this manner, the invention saves both 
processing and signaling resources. In addition, MSC-2 prepares a response in 
the form of a Configuration Capabilities Data Response message 23. This 

15 message includes capability and configuration information for MSC-2. In the 
exemplary message shown, MSC-2 indicates that it is compliant with the 3GPP 
R6 specification, it supports SNA and Service Handover, and it can handle a 
maximum of four bearers. Upon receipt of the Configuration Capabilities Data 
Response message, MSC-1 stores the included information, and uses the 

20 information to make future operations more efficient. 

Other capability and configuration data may also be included in the 
Configuration Capabilities Data Request message 22 and the Configuration 
Capabilities Data Response message 23. For example, proprietary information 
such as vendor identifications and vendor-specific features may also be 

25 indicated. Additionally, the messages may indicate exceptions to levels of 
functionality that are indicated. For example, if MSC-2 is compliant with 3GPP 
release version 6 except for one feature or capability, MSC-2 may indicate in its 
message that MSC-2 is compliant with 3GPP release version 6, but not the non- 
supported feature or capability. 

30 FIG. 3 is a flow chart illustrating the steps of one embodiment of the 

method of the present invention. At step 31 , the neighboring MSCs for MSC-1 
are defined. At some later time, as shown at step 32, MSC-1 may be 
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reconfigured and/or reset. At step 33, following the reconfiguration/reset. MSC-1 
sends its capability and configuration information to its neighboring MSCs. At 
step 34, the neighboring MSCs including, for example MSC-2, receive and store 
the MSC-1 capability and configuration information. At step 35, MSC-2 and the 
S other neighboring MSCs send their own capability and configuration information 
to M.SC-1 . 

At step 36, MSC-2 starts a service within the mobile communication 
network that requires the participation of other MSCs. At step 37, MSC-2 
determines, from the capability and configuration information that it has stored 

10 for other MSCs, whether or not MSC-1 supports the service. At step 38, upon 
determining that MSC-1 does not support the service, the method moves to step 
39 where MSC-2 does not send service-related information to MSC-1. This 
saves network bandwidth and relieves MSC-1 of the tasks of receiving the 
service-related information, analyzing the information to determine whether the 

15 information is useful, and discarding the information after determining that the 
information is for a service that MSC-1 does not support. However, upon 
determining at step 38 that MSC-1 does support the service, the method moves 
to step 40 where MSC-2 sends the service-related information to MSC-1 . Thus, 
information is only sent from one MSC to another when the receiving MSC 

20 supports the service or functionality with which the information is associated. 

Although the present invention has been described in detail with reference 
to only a few exemplary embodiments, those skilled in the art will appreciate that 
various modifications can be made without departing from the invention. 
Accordingly, the invention is defined only by the following claims, which are 

25 intended to embrace all equivalents thereof. 



